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RESUME. De nombreux modeles de composants sont aujourd'hui utilises a des fins variees : 
construction d 'applications, d'intergiciels, ou encore de systemes d 'exploitation. Ces modeles 
permettent tous des reconfigurations de structure, c 'est-a-dire des modifications de I 'architec- 
ture de V application. En revanche, peu permettent des reconfigurations d' implantation qui con- 
sistent a modifier dynamiquement le code des composants de V application. Dans cet article 
nous presentons le travail que nous avons effectue dans JULIA, une implementation Java du 
modele FRACTAL, pour permettre le dynamisme d 'implantation. Nous montrons comment les 
limitations du mecanisme de chargement de classes Java ont ete contournees pour permettre de 
modifier les classes d 'implementation et d 'interfaces des composants. Nous decrivons egale- 
ment I 'integration de notre proposition avec VADL de JULIA. 

ABSTRACT. Nowadays, numerous component models are used for various purposes: to build ap- 
plications, middleware or even operating systems. Those models commonly support structure 
reconfiguration, that is modification of application 's architecture at runtime. On the other hand, 
very few allow implementation reconfiguration, that is runtime modification of the code of com- 
ponents building the application. In this article we present the work we performed on JULIA, 
a Java-based implementation of the FRACTAL component model, in order for it to support im- 
plementation reconfigurations. We show how we overcame the limitations of Java class loading 
mechanism to allow runtime modifications of components ' implementation and interfaces. We 
also describe the integration of our solution with the JULIA ADL. 

MOTS-CLES : Systemes a composants, Java, Reconfiguration dynamique, Class loader, Fractal 
KEYWORDS: Component-based systems, Java, Dynamic reconfiguration, Class loader, Fractal 
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1. Introduction 

Les modeles de composants ont fait leur apparition dans les deux dernieres de- 
cennies. lis sont desormais utilises pour construire de nombreux systemes, aussi bien 
au niveau applicatif (EJB |ejb02|, CCM |MER 01 1) qu'au niveau intergiciel (dynamic - 
TAO | KON 01|, OpenORB | B LXon ). ou encore au niveau systeme (OSKit IFOR 971 . 
THINK | FAS 02 1). Un des apports des composants est qu'ils sont des briques logi- 
cielles independantes pouvant etre assemblies dynamiquement pour construire des 
logiciels complexes. L' aspect dynamique de F assemblage prend une importance crois- 
sante du fait de F evolution tres rapide des equipements informatiques et des besoins 
des utilisateurs d' applications. 

II est aujourd'hui communement admis de distinguer deux formes de reconfigura- 
tion dynamique d' applications |HOF 94 1 : reconfiguration de structure et reconfigura- 
tion d' implantation. Dans un systeme a composants, une reconfiguration de structure 
consiste a ajouter/enlever un composant, modifier une liaison entre composants, ou 
encore modifier la localisation d'un composant (si Fapplication est distribute). Une 
reconfiguration d' implantation consiste a mettre a jour le code d'un composant ou 
d'une ou plusieurs de ses interfaces. 

Si les modeles de composants permettent toujours des reconfigurations de struc- 
ture, il n'en n'est pas de meme pour les reconfigurations d' implantation, dont la mise 
en ceuvre peut etre tres difficile — voire impossible — suivant le langage d' implan- 
tation du modele de composants. Dans cet article, nous nous focalisons sur les mod- 
eles de composants implantes en Java. Java offre un systeme dynamique de charge- 
ment de classes, appele class loader. Celui-ci impose cependant un certain nombre de 
contraintes d' utilisation qui rendent difficile la mise a jour de code. II est par exem- 
ple impossible de charger deux versions d'une meme classe, ou encore de decharger 
une classe. Deux possibilites s'offrent aux developpeurs Java pour fournir des me- 
canismes de reconfiguration d' implantation : (1) modification du code des classes 
chargees pour garantir que deux versions d'une meme classe portent des noms dif- 
ferents ; (2) utilisation de class loaders differents pour charger les differentes versions 
d'une meme classe. La premiere solution preclut Futilisation d'une partie du langage 
Java : il n'est, par exemple, plus possible d'utiliser la methode de construction de 
classe Class. f orName("toto"), etant donne que celle-ci se base sur le nom de la 
classe a creer — nom qui peut avoir ete modifie lors du chargement. La seconde solu- 
tion est utilisee dans plusieurs serveurs J2EE : ceux-ci utilisent des hierarchies en arbre 
de class loaders, chaque class loader ayant un unique parent auquel il peut eventuelle- 
ment deleguer le chargement de classes. Ces organisations en arbre ne sont pas assez 
flexibles, et ne permettent que tres peu de reconfigurations d'implantation. 

Dans cet article, nous presentons le travail que nous avons mene au sein de Ju- 
lia IBRU 4b I. une implantation Java du modele de composants FRACTAL, pour 
permettre la co-existence de multiples versions d'une meme classe, et done la re- 
configuration d'implantation d'une application a composants. La solution que nous 
adoptons est d'utiliser une organisation arbitraire de class loaders : cette organisation 
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est construire en se basant sur les frontieres de composants et les besoins de reconfig- 
urabilite exprimes par le developpeurd' applications a l'aide du langage de description 
d' architecture de Julia. Les class loaders sont crees et administres a l'aide de Mod- 
ule loader 1HAL 041 . un systeme permettant de faire cooperer un ensemble de class 
loaders. 

L' article s'organise de la facon suivante : nous presentons le modele de composants 
Fractal et son implantation, Julia, dans la section[2] La section [3]presente notre 
proposition pour la reconfiguration d' implantation dans Julia. Son implemantation 
est decrite dans la section|4] Enfin, nous presentons les travaux connexes dans la sec- 
tion|5J avant de conclure cet article. 

2. Le modele de composants Fractal 

Le modele de composants FRACTAL I B RU 04al IBRU 4b I est un modele flexi- 
ble et reflexif. Contrairement a d'autres modeles comme Jiazzi |MCD 01 1 ou Arch- 
Java IALD 021. Fractal n'est pas une extension a un langage, mais une librairie qui 
permet la creation et la manipulation de composants et d' architectures a base de com- 
posants. Dans la suite de cette section, nous presentons Julia, une implantation Java 
de Fractal 



2.1. Le modele 

Julia distingue deux types de composants : les composants primitifs sont es- 
sentiellement des classes Java standards avec quelques conventions de codage. Les 
composants composites encapsulent un groupe de composants primitifs et/ou compos- 
ites. Une caracteristique originale du modele est qu'un composant peut etre encapsule 
simultanement dans plusieurs composites. Un tel composant est appele composant 
partage. 

Un composant est constitue de deux parties : la partie de controle — qui expose 
les interfaces du composant et comporte des objets controleurs et intercepteurs — , 
et la partie fonctionnelle — qui peut etre soit une classe Java (pour les composants 
primitifs), soit des sous-composants (pour les composants composites). 

Les points d'acces d'un composant sont appeles interfaces. On distingue deux 
types d' interfaces : les interfaces serveurs sont des points d'acces acceptant des appels 
de methodes entrants. Elles correspondent done aux services fournis par le composant. 
Les interfaces clients sont des points d'acces permettant des appels de methodes sor- 
tants. Elles correspondent aux services requis par le composant. Ces deux types d'in- 
terfaces sont decrits par une signature Java standard et une indication sur le role de 
l'interface (client ou serveur). 

La communication entre composants Julia est uniquement possible si leurs inter- 
faces sont liees. Julia supporte deux types de liaisons : primitives et composites. Une 
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liaison primitive est une liaison entre une interface cliente et une interface serveur ap- 
partenant au meme espace d'adressage. Elle signifie que les appels de methodes emis 
par l'interface cliente doivent etre acceptes par 1' interface serveur. Une telle liaison est 
dite "primitive" car elle est mise en ceuvre de facon tres simple a l'aide d'une reference 
Java. Une liaison composite est un chemin de communication entre un nombre arbi- 
traire d'interfaces de composants. Ces liaisons sont construites a l'aide d'un ensemble 
de liaisons primitives et de composants de liaisons (stubs, skeletons, adaptateurs, etc). 



2.2. Exemple 

La figure[Oillustre les differents concepts du modele de composants FRACTAL. Les 
rectangles representent des composants : la partie grisee correspond a la partie con- 
trole des composants ; l'interieur du rectangle correpond au contenu des composants. 
Les fleches correspondent aux liaisons entre interfaces (representees par des structures 
en forme de "T"). Les interfaces externes apparaissant au sommet des composants sont 
les interfaces de controle. Les deux rectangles gris representent un composant partage. 
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Figure 1 - Exemple d' application FRACTAL 



2.3. Implantation 

Un composant Julia est forme de plusieurs objets Java que Ton peut separer en 
trois groupes (figure|2j : 

- Les objets qui implementent le contenu du composant. Ces objets n'ont pas ete 
representes sur la figure. lis peuvent etre des sous-composants (dans le cas de com- 
posants composites) ou des objets Java (pour les composants primitifs). 

- Les objets qui implementent la partie de controle du composant (representes en 
noir et en gris). Ces objets peuvent etre separes en deux groupes : les objets imple- 
mentant les interfaces de controle, et des intercepteurs optionnels qui interceptent les 
appels de methodes entrant et sortant sur les interfaces fonctionnelles. 

- Les objets qui referencent les interfaces du composant (en blanc). 
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Figure 2 - Implantation d'un composant Julia 



La mise en place de ces differents objets est effectuee par des fabriques de com- 
posants. Celles-ci fournissent une methode de creation qui prend en parametres une 
description des parties fonctionnelles et de controle du composant. Dans F implemen- 
tation actuelle de Julia, toutes les fabriques de composants utilisent le meme class 
loader. 



3. Vers une reconfiguration d' implantation dans JULIA 

Tel que defini dans la section precedente, Julia fournit un support pour la re- 
configuration de structure : en effet, les controleurs des composants permettent d'a- 
jouter/retrancherdes composants, ou encore de modifier les liaisons entre composants. 
En revanche, Julia ne fournit aucun support pour la reconfiguration d' implantation. 
En effet, Fensemble des classes chargees dans une machine virtuelle Java (i.e. dans le 
meme espace d'adressage) sont chargees par le meme class loader. En consequence, il 
n'est pas possible de faire co-exister deux versions d'une meme classe, ce qui exclut 
les reconfigurations d' implantation. Nous commencons cette section par une descrip- 
tion des differentes contraintes imposees par le class loader Java, puis nous decrivons 
notre proposition. 



3.1. Les contraintes du class loader Java 



Le class loader Java | SHE 98 1 permet de charger dynamiquement des classes Java 
au sein d'une machine virtuelle. Chaque class loader charge les classes a partir d'une 
source definie : systeme de fichiers, reseau, etc. Le role d'un class loader est de creer 
des objets Class a partir de fichiers . class. Pour ce faire, chaque class loader imple- 
mente une methode loadClass (String name) qui a pour but de charger une classe. 
Cette methode utilise la methode findLoadedClass (String name) pour verifier 
que la classe n'a pas deja ete chargee, auquel cas elle est stockee dans un cache. Si 
tel n'est pas le cas, loadClass utilise def ineClass pour construire un objet Class 
a partir d'un tableau d'octets. Notons qu'un class loader peut egalement deleguer le 
chargement d'une classe a un autre class loader. Ce mecanisme est majoritairement 
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utilise avec des hierarchies en arbre de class loaders : chaque class loader a un pere 
auquel il peut deleguer le chargement. 

II est important de noter qu'une classe est liee au class loader qui l'a chargee : 
la meme classe chargee par deux class loaders differents est considered comme deux 
classes differentes. En consequence, l'utilisation d'une classe a la place de l'autre leve 
une exception ClassCastException. 



3.2. Les class loaders dans un monde de composants 

Une application FRACTAL est constitute d'un ensemble de composants. Chaque 
composant est constitue d'un ensemble de classes (decrites dans la section [2j. La 
question a laquelle nous devons repondre est : a quels class loaders faut-il deleguer le 
chargement de chacune des classes ? 

Selon Szyperski I SZY 981 . "un composant est deployable independamment et est 
sujet a composition par une tierce partie". Une approche naive pour rendre les com- 
posants deployables independamment consiste a charger chaque composant dans un 
class loader independant. Cependant de tels composants ne sont pas composables par 
une tierce partie. En effet, toute tentative de liaison entre les interfaces de deux com- 
posants resulterait en une exception ClassCastException. 

II apparait done logique de separer les classes d' interfaces du composant (fonc- 
tionnelles et de controle) — destinees a etre utilisees par les autres composants — , 
des classes d 'implementation — destinees a 1' usage "prive" du composant. Supposons 
que Ton ait deux composants C\ et Ci qui communiquent via une interface Push qui 
definit une methode void push (Message m) . Les classes Push et Message doivent 
etre chargees par un class loader commun aux deux composants tandis que les classes 
d' implantation des composants peuvent etre chargees independamment. 

Cette solution n'est neanmoins pas suffisante. Supposons que la signature de la 
methode push soit differente : void push (Object o). II est necessaire que toutes 
les classes des objets transitant via la methode push soient chargees dans un class 
loader commun a C\ et Ci- Ces classes, appelees classes partagees, sont un sous- 
ensemble des classes d' implementation des composants. 



4. Mise en oeuvre 

Dans cette section, nous presentons la mise en oeuvre de la proposition formulee 
dans la section precedente. Nous decrivons l'utilisation de Module loader pour l'inte- 
gration des classes loaders dans Julia, puis nous montrons comment 1' ADL de Julia 
a ete etendu pour permettre la specification de versions d' interfaces, du code partage, 
et l'instanciation des differents class loaders. 
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4.1. Module loader 

Module loader I H AL 04-1 est un canevas permettant de construire des organisa- 
tions arbitrages de class loaders, respectant une logique de chargement definie par le 
developpeur. Les principaux concepts de Module loader sont : module, module man- 
ager, resource source et search policy. 

- Le module est une unite logique de groupement de ressources (i.e classes). 
Chaque module est associe a un class loader. Par ailleurs, chaque module peut definir 
des meta-donnees. 

- Un module manager gere un ensemble de modules. II envoie des notifications 
quand des modules sont ajoutes ou retrenches. 

- Une resource source est une source a partir de laquelle un module peut charger 
des classes. Cette source peut etre un fichier, une URL, une base de donnees, etc. Les 
concepteurs de modules peuvent definir leurs propres sources. 

- La search policy est le "cerveau" du mecanisme de chargement de classes. II 
definit la facon dont un module peut localiser (et done charger) une classe. La search 
policy adapte son comportement en fonction des evenements qu'elle recoit du module 
manager. Un exemple typique de search policy est F import search policy : les modules 
annoncent (via des meta-donnees) les ressources qu'ils exportent (i.e. fournissent) aux 
autres modules, et les ressources qu'ils importent (i.e. requierent) des autres modules. 
Un module ne peut etre cree que si les ressources qu'il importe sont presentes. 

4.2. Utilisation de Module loader dans JULIA 

4.2.1. Les differentes structures de donnees 

Comme nous Favons vu dans la section|3] chaque composant utilise des class load- 
ers differents pour les classes d' implementation, d'interfaces, et les classes partagees. 
L information sur les classes requises par un composant est stockee dans un module, 
appele Info Module. Un Info Module ne charge pas de classes. II delegue le charge- 
ment des classes a des Resource Modules, qui donnent acces a des classes et a des 
informations sur ces classes. Les Resource Modules sont crees en accord avec les re- 
gies enoncees dans la section : un module par implementation de composant, un 
module par classe d'interface, et un module pour les classes partagees. 

La figure [3]presente un exemple d' organisation de modules. L application fait in- 
tervenir deux composants, chacun d'eux etant implements par un certain nombre de 
classes. Les composants communiquent via une interface representee par l'interface 
Cmpltf . Par ailleurs, les composants echangent une classe partagee Exchangedltf . 
L organisation des modules respecte les regies enoncees au paragraphe precedent : 
chaque composant est associe a un Info Module qui delegue le chargement des classes 
a different Resource Modules. Cette delegation se base sur les meta-donnees de chaque 
module. 
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Figure 3 - Organisation des modules 



4.2.2. Comportement des modules a V execution 

Quand un composant est cree, le class loader de son Info Module devient le class 
loader courant. Quand une classe doit etre chargee, YInfo Module cherche un Ressource 
Module, parmi ceux qu'il connait, qui peut charger la classe requise dans la version 
appropriee. Cette classe est chargee par le class loader associe au Ressource Module. 

Par ailleurs, il est necessaire que lorsque les composants communiquent, le flot 
d'execution des requetes (i.e le thread) soit associe aux class loaders appropries. Par 
exemple, si un appel "traverse" quatre composants, il est necessaire que lors du transit 
de 1' appel dans chacun des composants, le class loader du flot d'execution soit mis a 
jour : pour chaque composant, il doit etre positionne sur YInfo Module du composant. 
Pour ce faire, nous avons developpe un intercepteur dont le role est d' intercepter toutes 
les requetes pour modifier le class loader du flot d'execution. Le mecanisme d' inter- 
ception engendre un leger surcout des temps d'execution. Ce surcout est de l'ordre de 
3 a 4%. 
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4.3. Extension de 1'ADL Julia 

Le langage de description d' architecture (ADL) de Julia permet de decrire des 
applications a base de composants Julia. L' ADL a ete concu de maniere extensible : 
il est compose de plusieurs modules, chacun definissant une syntaxe pour exprimer un 
"aspect" de 1' architecture (interfaces, liaisons, attributs, etc.)- Les developpeurs sont 
libres de creer leurs propres modules. 

Une fabrique est en charge d'utiliser la description de l'application pour creer l'ar- 
chitecture correspondante (creation et liaison des composants, positionnement des at- 
tributs, etc.). De facon similaire a l'ADL, cette fabrique a ete concue de maniere ex- 
tensible, afin de pouvoir y integrer du code relatif aux modules ADL definis par le 
developpeur. 

Nous avons cree un module permettant de specifier les versions de composants 
et d' interfaces utilisees par l'application. Ce module permet egalement de specifier 
les classes partagees de chacun des composants. La figure |4] donne un exemple de 
description ADL. Lattribut version a ete ajoute aux definitions d'interfaces et de 
contenu. Par ailleurs, l'element f ile permet de specifier les classes qui sont partagees, 
i.e. qui sont echangees par les composants, via leurs interfaces. 



<definition name="HelloWorld" version="2 . 0"> 






<interface name="r" role="server" 






s ignature= " j ava . lang . Runnable " /> 






<component name="client"> 






<interface name="r" role="server" 






signature= " j ava . lang . Runnable 


"/> 




<interface name="s" role="client" 






signature="Service" version=" 


1.0' 


/> 


<content class="ClientImpl" version="1.0 


"/> 




<file name="Request" version="l . 0"/> 






</component> 






<component name="server"> 






<interface name="s" role="server" 






signature="Service" version=" 


1.0' 


/> 


<content class="ServerImpl" version="2.0 


"/> 




<file name="Request" version="l . 0"/> 






</component> 






<binding client="this .r" server="client . r"/> 






<binding client="client . s" server="server . s" 


/> 




</def inition> 







Figure 4 - Un exemple de description ADL 

Nous avons egalement developpe un module pour la fabrique associee a l'ADL. 
Ce module a la responsabilite de determiner les class loaders necessaires, et de creer 
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les Info Modules et Ressources Modules appropries. Le developpeur d' applications 
peut configurer deux aspects de ce module : la granularite des class loader crees (en 
fonction de la granularite de reconfiguration souhaitee), et les sources des classes req- 
uises par l'application. A l'heure actuelle, nous n'offrons la possibilite que de deux 
granularites : un seul class loader — ce qui correspond au comportement de Julia 
et ne permet pas de reconfiguration dynamique — , et la granularite definie dans les 
sections precedentes. Nous sommes en train de developper un module permettant 
au developpeur de specifier les composants qu'il veut pouvoir charger/decharger dy- 
namiquement. Concernant la specification des sources de classes, nous ne permettons 
actuellement que de specifier des fichiers . class et des fichiers . j ar. 



5. Travaux connexes 

On peut distinguer trois courants dans les travaux sur le developement de canevas 
a composants extensibles en Java : les modeles de composants, les plates-formes de 
services, et les serveurs J2EE. 

Parmi les modeles de composants, citons JPloy ILUE 041 et SOFA |HNE03|. 
Ces deux modeles utilisent des manipulations de bytecode pour garantir que les dif- 
ferentes versions d'une meme classe sont chargees avec des noms differents. Ces 
noms sont generes a partir de fichiers de descriptions (comparables a des descrip- 
tions ADL) qui specifient les versions des classes utilisees. L'avantage de cette ap- 
proche est qu'elle n'engendre aucun surcout a 1' execution. En revanche, elle rend 
impossible F utilisation de certaines methodes du langage Java. II n'est, par exemple, 
pas possible d'utiliser certaines methodes de construction de classe par reflexion (e.g. 
Class . forName (String name)). 

Les plates-formes de services sont apparues ces dernieres annees avec les travaux 
menes sur OSGi | osg03 1 . OSGi permet de deployer des applications Java empaquetees 
sous formes de bundles. Un bundle contient des fichiers jar et des meta-donnees sur 
ces fichiers jar (version, etc.). Le role d'une plate-forme OSGi est de gerer le cycle 
de vie des bundles (deploiement, activation, retrait, etc.). Un des apports d'OSGi pour 
la communaute Java est la prise en compte des versions des fichiers jar. Neanmoins, 
OSGi impose certaines contraintes : il ne permet, par exemple, pas de faire co-exister 
deux versions d'une meme classe. Par ailleurs, le modele de composants utilise dans 
OSGi est un modele plat : il n'est pas possible de creer des bundles "composites". 

Enfin, de nombreux travaux sont effectues sur le chargement de classes dans les 
serveurs J2EE |j2e02[ (IBM WebSphere Iweb03l . BEA WebLogic Iwebl. JOnAS fioii) , 
etc.). Le but est de pouvoir isoler les differentes applications deployees sur un serveur. 
Les class loaders sont organises en arbre, ce qui s'avere suffisant pour les applications 
ciblees, mais qui est trop restrictif dans un modele de composants plus flexible comme 
Fractal. 
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6. Conclusion 

II existe aujourd'hui de nombreux modeles de composants utilises dans des do- 
maines varies : applications pour l'lnternet, intergiciels, systemes d' exploitation, etc. 
Si ces modeles supportent tous le dynamisme de structure — qui consiste en une mod- 
ification de F architecture de l'application s'executant — , peu, en revanche, supportent 
le dynamisme d' implantation — qui consiste a modifier dynamiquement le code des 
composants de l'application. 

Dans cette article, nous avons presente le travail que nous avons effectue au sein 
de Julia, une implementation Java du modele FRACTAL, pour ajouter des capacites 
de reconfiguration d' implantation. Nous avons montre comment contourner les limi- 
tations imposees par le class loader — le mecanisme Java de chargement de code — 
pour permettre aux composants de modifier leur implementation et leurs interfaces. 

La solution que nous proposons est plus flexible que celle mise en ceuvre dans 
les serveurs J2EE, et ne presente pas les contraintes de celles reposant sur des mod- 
ification du bytecode des classes des composants. Par ailleurs, F integration de notre 
proposition dans l'ADL Julia la rend transparente au developpeur de composants. 

Nous poursuivons actuellement nos travaux pour permettre au developpeur de spe- 
cifier le niveau de granularite qu'il souhaite, c'est-a-dire les composants qu'il souhaite 
pouvoir charger/decharger dynamiquement. 



7. Bibliographie 

[ALD 02] ALDRICH J., CHAMBERS C, NOTKIN D., « Architectural Reasoning in Arch- 
Java », Proceedings 16th European Conference on Object-Oriented Programming 
(ECOOP), 2002. 

[BLA01] Blair G., Coulson G., Andersen A., Blair L., Clarke M., Costa F, 

DURAN-LlMON H., FlTZPATRICKT., JOHNSTON L., MOREIRA R., PARLAVANTZAS N., 
, SAIKOSKI K., « The Design and Implementation of Open ORB v2 », IEEE Distributed 
Systems Online Journal, vol. 2 no. 6, Special Issue on Reflective Middleware, November 
2001. 

[BRU 04a] BRUNETON E., COUPAYE T., STEFANI J.-B., « The Fractal Component Model, 
Specifications », 2004, The ObjectWeb Consortium, http ://www.objectweb.org. 

[BRU 04b] BRUNETON E., COUPAYE T., LECLERCQ M., QUEMA V., STEFANI J.-B., « An 
Open Component Model and its Support in Java », Proceedings of the International Sympo- 
sium on Component-based Software Engineering ( CBSE'2004), Edinburgh, Scotland, 2004. 

[ejb02] « Enterprise JavaBeansTM Specification, Version 2. 1 », August 2002, Sun Microsys- 
tems, http : // java. sun. com/products/ejb/. 

[FAS 02] FASSINO J. -P., STEFANI J.-B., LAWALL J., MULLER G., « THINK : A Software 
Framework for Component-based Operating System Kernels », U SEN IX Annual Technical 
Conference, 2002. 



182 DECOR'04, Deploiement et (Re)Configuration de Logiciels. 

[FOR 97] Ford B., Back G., Benson G., Lepreau J., Lin A., Shivers O., « The Flux 
OSKit : A Substrate for Kernel and Language Research », ACM Symp. on Operating 
Systems Principles (SOSP), 1997. 

[HAL 04] HALL R. S., « A Policy-Driven Class Loader to Support Deployment in Extensible 
Frameworks », Proceedings of the 2nd International Working Conference on Component 
Deployment (CD'2004), Edinburgh, Scotland, 2004. 

[HNE 03] HNETYNKA R, Tuma P., « Fighting Class Name Clashes in Java Component Sys- 
tems », Proceedings of the Joint Modular Language Conference (JMLC'2003), Klagenfurt, 
Austria, 2003. 

[HOF 94] HOFMEISTER C, « Dynamic Reconfiguration of Distributed Applications », PhD 
thesis, University of Maryland, 1994. 

|J2e02] « J2EE : Java 2 Platform, Enterprise Edition », 2002, 
http ://java.sun.com/j2ee/docs.html. 

[jon] « JOnAS class loader hierarchy », 

http ://www.huihoo.com/jonas/white_paper/ClassLoader.html. 

[KON 01] Kon F., Yamane T., Hess K., Campbell R. H., Mickunas M. D., « Dynamic 
Resource Management and Automatic Configuration of Distributed Component Systems », 
Proceedings of the 6th USENIX Conference on Object-Oriented Technologies and Systems 
(COOTS'Ol), San Antonio, USA, January 2001. 

[LUE04] LUER C, VAN DER HOEK A., « JPloy : User-Centric Deployment Support in a 
Component Platform », Proceedings of the 2nd International Working Conference on 
Component Deployment (CD'2004), Edinburgh, Scotland, 2004. 

[MCD01] McDlRMID S., FLATT ., HSIEH W., « Jiazzi : New-age components for old- 
fashioned Java », Proceedings OOPSLA '01, ACM Press, 2001. 

[MER 01] MERLE P., Ed., CORBA 3.0 New Components Chapters, OMG TC Document 

ptc/2001-11-03, November 2001. 
[osg03] « Open Services Gateway Initiative, OSGi service gateway specification, Release 3 », 

April 2003, http : //www . osgi . org. 

[SHE 98] SHENG L., BRACHA G., « Dynamic Class Loading in the Java Virtual Machine », 

Proceedings of the International Conference on Object-Oriented Programming, Systems, 
Languages, and Applications {OOPSLA' 98), 1998. 

[SZY 98] SZYPERSKI C, Component Software : Beyond Object-Oriented Programming, 
Addison-Wesley, 1998. 

[web] « WebLogic Server Application Classloading », WebLogic Server 8.1 Documentation, 
http ://edocs. bea.com/wls/docs8 1/programming/classloading.html. 

[web03] « WebSphere Software Information Center, Class loaders », 2003, http ://pub- 
lib.boulder.ibm.com/infocenter/wasinfo/topic/com.ibm.websphere.base.doc/info/aes/ae/ 
crun_classload.html. 



